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Until recently, much of the budget planning for software 
systems has been primarily targeted at costs incurred during 
the development phase. However, with increasing software 
system life span and complexity, maintenance costs have 
become a mere prevalent concern. As a result of necessary 
corrections for design errors and evolutionary maintenance, 
post-delivery investment in software systems now requires a 
greater proportional share of the life-cycle costs. In this 
research, various methodologies and system factors relating 
to software cost accounting are reviewed with the intent of 
developing a cost control model for arriving at a 
well-structured view for the management of the maintenance 
phase of the software life-cycle. The model proposed 
embodies a planning concept for establishing a maintenance 
strategy and a control concept for analyzing manloading 
requirements during the maintenance phase. 
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I. 



INTROD UCT ION 



A. THE PROBLEM 

Recent literature is replete with dire predictions about 
the ultimate costs of software maintenance. In 1973, costs 
of software in the United States were 520 billion [1] and 
they are projected to be $200 billion in 1985 [2]. It has 
been hypothesized that anywhere from forty to ninety-five 
percent cf the manpower effort in typical industrial appli- 
cations occurs during the maintenance phase cf the software 
life cycle. [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14] 

Although there are numerous models in existence that 
deal with software costs, none deal specifically with the 
costs of 'pure' maintenance during the latter phase of the 
software life-cycle. It appears that much of the Federal 
Government and industry tend to use a general definition of 
software maintenance and treat it as a level of effort on 
various tasks rather than that effort allocated to specific 
tasks. Consequently, these organizations do not really 
know the true costs cf their software maintenance. 

The goal of this work is to investigate the methodology 
of software cost accounting, and to evaluate and develop a 
cost model for the prediction of pure software maintenance 
costs . 
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3. 



3 AC K GROUND 



The term ‘Software Maintenance’ is very nebulous. De- 
partment of Defense Directive 5000.29 alludes to software 
maintenance by stating: 

'•Correctness of software, reliability, integrity, main- 
tainability, ease of modification, and transferability 
will be major consider ations in the initial design." 
[15] 

Used in this thesis is a composite definition of software 
maintenance to encompass those actions taken by a system 
user to retain an existing system in, cr restore it to, an 
operable condition. This includes: 

1) corrections to counteract detected tugs; 

2) enhancements to add functions; 

3) modifications to delete or change existing functions in 
their nature or scope; 

4) imolementaticn strategy to match changed conditions or 
requirements. [16, 17, 18, 19, 20, 21, 22, 23, 24] 

'Pure* Maintenance on the other hand is restricted to 



that work accomplished during the maintenance phase of the 
software life cycle in the pursuit of the following goals: 

1) Relialibility of Software - the ability of the software 
to produce consistent results whenever the customer 
uses the product; 

2) Error Correction - changes made tc counteract errors. 
The priority of correction is directly related to the 
seriousness of the error; 

3) Software Maintainability - extending the useiul life of 
a oroaram by untangling a messy one, generalizing a 
specific one, cr annotating an unreadable one. 

13 



Robert Glass [25] defines the best software maintenance 
as no maintenance at all. That is, no changes are needed be- 
cause no errors were committed and all changes were antici- 
pated. He then goes on to list six attributes of software 
maintenance : 



1) Maintenance is intellectually very difficult. Problems 
cannot be bounded. The cause ccula be anywhere. 

2) Maintenance is technically very difficult. Problems 
cannot be specialized. They could surface because of 
errors in the coding, design, architecture, cr concept. 



3) Maintenance is unfair. Usually the person who is main- 
taining a product did not write it and must interpret 
what the original author meant. Documentation is in- 
adequate most of the time. 



4) Maintenance is nc-win. People only come to maintenance 
with problems. 



5) Maintenance is infamous. There is very little glory, 
noticeable progress, or chance for ’success’. 



6) Maintenance lives in the past. The general quality of 
code being maintained is often terrible. This is part- 
ly because it was created when everybody's understand- 
ing of software was mere rudimentary, and partly be- 
cause a great deal of code is produced by 
they become really good at programming. 



people before 



Researchers dc not appear to be using the same defini- 



tion when working on the costs of maintenance. Those who es- 
timate maintenance costs to be near forty percent of life- 



cycle costs seem to be using a definition closer to that of 
•pure' maintenance while those who estimate maintenance as 
high as ninety-five percent are obviously using a very 
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general definition. According to recent surveys, most 
(seventy to eighty-eight percent) maintenance effort is 
spent modifying software to accomodate changes and to im- 
prove software performance rather than to correct errors 
which were not discovered during systems development. [26, 
27, 28] These surveys have been substantiated by analyses 

done on three large scale systems: 

1) Pacific Telephone - Service Order Retrieval and Distri- 
bution System; 

2) Bell Telephone Laboratories - Automated Repair Service 
Bureau System; 

3) VISA, Inc. - Base II World wide Credit Card Transaction 
Interchange System. [29] 

Although hardware costs have decreased by over two 
orders of magnitude and programmer productivity has in- 
creased by one order of magnitude in the last ten years, the 
total costs of systems are continuing to rise wi th the 
greatest portion of effort and cost spent after development 
completion [30], There appear to be four primary reasons 
for this phenomenon: 

1) Maintenance is people intensive; 

2) The number cf systems has increased substantially; 

3) The mission of the software seems to be expanding; 

4) Average system life has increased from three years in 
1960 to five vears in 1970 to eight years in 1980. 
[31, 32] 
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A recent DOD study reports that development costs for 
Air Force avionics software averaged $75 per instruction 
while maintenance costs lie in the range of $4,000 per in- 
struction [33] This indicates that ninety-eight percent of 
the life-cycle costs of that system are spent on software 
maintenance. Another study concludes that fifty percent of 
the costs for Navy Airborne Antisubmarine Warfare Tactical 
Software is spent on maintenance software [34]. As one can 
see, there are many different meanings of the term 'software 
maintenance' and as many different assessments of its cost. 

The software industry does not appear to be unified in 
its approach to decreasing trhe high ccst of maintenance. 
McClure states: 

"A solution that focuses upon the production phases of the 
software life cycle does not address the major portion of 
the maintenance effort... We must directly address 
maintenance issues rather than hope that they will disap- 
pear by improving the development process." [35] 

Most of the literature expounds the theory that, to be done 
properly, software maintenance should be a conscious goal 
from the beginning cf the software development process. 
Maintenance is all too often left out of planning considera- 
tions and then treated as a helter-skelter, uncoordinated 
activity rather than a planned, methodical, controlled nec- 
essary business function [36]. Long term planning, just as 
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in ether disciplines, includes the provision of appropriate 
tools. There are two major categories cf tools for mainte- 
nance. Technical tools encompass such things as compilers, 
traps and traces, dumps, comparators, editors, reformatters, 
and preprocessors. Administrative tools include problem re- 
porting vehicles, status reporting vehicles, and documenta- 



tion systems. (37, 38, 39] 



Sven with the knowledge and use of these tools, produc- 
tivity, which is typically measured in software lines of 
code {SLOC) is substantially lower for maintenance program- 
mers than for development programmers. According to Daly, 
maintenance productivity can be as low as twenty percent of 
development productivity (40]. There appear to be three 
main reasons for this phenomenon: 



1) There is a stigma attached to the job of software 
maintenance. Management rarely rewards good work in 
doing maintenance as generously as good work in doing 
development. Both coworkers and manaaement personnel 
act as though they held maintenance work in low esteem. 
To survive, every person must have self respect. If a 
job is not perceived as important, a person probably 
will not perform to the best of his abilities. 



2) Usually, maintenance personnel are not intimately fa- 
miliar with the code that they are assigned to main- 
tain. Typically, a maintainer is assigned responsibil- 
ity for 30,000 SLOC [41], Eecause documentation is 
guite often poor, the maintainer must study the code 
itself and try to understand what the original develop- 
er created and why he implemented it in that manner. 
Usually he must study a great deal more code than the 
affected area to avoid inducing bugs in a seemingly un- 
related area by the fix that is implemented. 



3) The wrong grade of people are typically used to staff 
maintenance efforts (42, 43, 44, 45, 46, 47, 4 S t 49] 

Traditionally, maintenance efforts are being starred by 
less experienced personnel than development projects. 
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However, maintenance personal should be senior people 
because software maintenance is a microcosm of the en- 
tire software development process. The maintainer does 
a systems analysis of a problem area leading to a re- 
quirements definition. Donning a designer's hat, the 
maintenance person then outlines the impact or the 
change on the product. Being a flexible individual, 
the maintainer now codes the design solution. After 
the results of these efforts have been tested and veri- 
fied, the revised product is finally released to the 
world. The maintenance person also plays a liaison 
role with the customer by explaining anomalous outputs, 
negotiating changes that are needed as opposed to those 
that are desired, and interpreting the computer's 
unique constraints. As you can see, the person who 
maintains a complex system should be a highly talented 
and motivated individual. [50, 51, 52] 



C. RESEARCH METHODOLOGY 



1 . Literature Search 



Manual searches and automated system searches of the 
literature showed little had been published in this field. 
Although there is a lack of published material that deals 
directly with a fiscal approach to planning and control of 
software maintenance, the researchers found a great deal 
that was very useful as background information and which 
helped to develop the theory for the planning and control 



model . 



2 . Te lephon e Co n versations 

Efforts to uncover informal sources that deal spe- 
cifically with the costs of 'pure maintenance* failed. The 
following organizations were contacted in the course of the 
research, with no significant results: 

Army Computer Systems Command, Ft. Belvoir, 7a. ; 

DOD Computer Institute, Washington, D.C.; 
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FEDSIM, Washington, D.C.; 

Homestead Software Support Facility, Homestead, FI. ; 

ISM Federal systems Division, Gathersburg , Md.; 

Kapur Associates, Danville, Ca. ; 

National Security Agency, T303, Ft. Meade, Md. ; 

Naval Security Group Activity, Skaggs island, Ca. ; and 

NARDAC San Francisco, Alameda, Ca. 

Maintenance tracking data, dealing with Goddard 
Space Flight Center projects, was obtained from the Data and 
Analysis Center for Software, Griffis A FB, NY. Unfortunate- 
ly, the late arrival of the data and format incompatibility 
precluded inclusion of this data. 

Unpublished documents describing a matrix management 
method of functional area analysis developed by Mr. Kyle 
Rone, IBM Federal Systems Division, Houston, Tx. were 
obtained and significantly contributed to the formulation of 
the final model. 

D. ORGANIZATION OF THE THESIS 

In this introduction the problem has been stated, its 
importance discussed, and it has been placed in the context 
of the overall computer system development process. Chapter 
two covers various aspects of the problems encountered when 
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estimating/deter mining the cost of software maintenance. 
This specific background material is needed to understand 
the models that will be presented in chapters three and 
four. Chapter three thoroughly discusses existing models in 
two areas: those that work with Norden-Rayleig h curves, and 
those that encompass complexity metrics. Chapter four gives 
the authors' model which is based on both macro-estimating 
(total system) and micro-estimating (unit composition) tech- 
niques. Finally, chapter five summarizes the thesis and 
puts forth, conclusions and recommendations. 
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II. QUANTIFYING SOFTWARE MAINTENANCE 
A. THE SOFTWARE EROBIEM 

Thera are twc main reasons that maintenance has become a 
predominant cost in software systems. First, the volume of 
completed systems which require maintenance dominates the 
systems under development as more and more long-lived large 
systems are completed and delivered. Second, software sys- 
tems require a considerably greater proportional investment 
in error correction and evolutionary maintenance after de- 
livery than other engineering products. 

Numerous technological advances have not solved software 
problems. They have increased the demand for software, and 
opened up opportunities to use computers in new applications 
which place increasingly severe demands on software tech- 
nology. Often the tendency is simply to ignore these prob- 
lems. Because these problems are both technical and mana- 
gerial in their scope, a “systems engineering” solution is 
needed. 

Unlike hardware operation and support models, where the 
cost of spares, maintenance manhours, material, training, 
etc., can be estimated based on some physical characteris- 
tics of the system, software maintenance effort is strictly 
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a function of manhours to perforin the necessary action. 
Thus far, maintenance costs for software seem to be primari- 
ly an estimate by an expert, someone familiar with the 
changes to be made to a program, rather than putting certain 
parameters into a cost estimating relation and calculating 
annual maintenance costs. 

Software maintenance costs cannot be ascribed to one 
specific agent or event but instead to the combined action 
of many factors. By reviewing some of these, the complexity 
of the problem can be better understood. In this research, 
an attempt is made tc isolate areas that can be estimated by 
formulas and then to establish the mathematical relation- 
ships. As such, the following topics will be discussed as 
they relate to the maintenance function: 

1) Software Life-cycle; 

2) Life-cycle Interrelationships; 

3) Software Evolution; 

4) Productivity; 

5) Complexity Metrics; ana 

6) Error Prediction. 
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B. THE SOFTWARE LIFE-CYCLE 



In the mid 1970's, the phrase "software life-cycle" was 
coined and became a popular means for conveying the basic 
concepts of a software system; multiple phases and extended 
life. Many representations of the life-cycle exist; by com- 
monly accepted practice, the software life-cycle consists of 
the development phase and the maintenance phase taken col- 
lectively. Depicted in Figure 2.1 is a composite schematic 
showing this relationship. 

This diagram oversimplifies the importance of the 
maintenance phase. A more accurate role of the maintenance 
function is detailed in the life cycle model (figure 2.2) 
developed by Rome Air Development Center [53]. From this 
view, maintenance performed during the operation and support 
phase is seen to be a highly interactive process. The con- 
jecture apparent from the diagram is that the same procedur- 
al requirements fcr software development must be duplicated 
during the maintenance phase. 

The basis of applying a life-cycle management scheme to 
software is to direct attention to all phases encompassed by 
the system life-cycle and the contribution of each phase to 
the total life-cycle expenditures. Familiarity with and 
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Figure 2.2. Software Life-cycle 
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understanding of the life-cycle can help managers make ef- 
fective distribution of the resources for a software system 
which will ultimately affect, the maintainability of the 
software. 

The life-cycle curves, more recently called "Rayleigh" 
curves, were orginally formulated by Lord Rayleigh, the 
British Nobel Laureate. Presently, these curves are used to 
represent resource allocation (manpower) of a software pro- 
ject. Preliminary research in this area was directed at re- 
source consumption in research and development (RSD) pro- 
jects. In a series of studies conducted by Peter Norden 
[54] of IBM, it was established from a large body of empiri- 
cal evidence that large RSD projects follow a life-cycle 
pattern as described by the Rayleigh (manpower) equation: 

2 

-at 

y » = 2Kate (2. 1) 

where 

v' = the number of person-years of effort expended 
per year, 

X = the total numEer of person-years required over 
the life-cycle, 

a = the curve shape parameter, 
t = elapsed time in years, and 
e = exponential function. 
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The principle of the curve xs as follows: Research has 
indicated that there are regular patterns of manpower build- 
up and phase-out in complex projects. These patterns are 
made up of a small number of successive phases or cycles of 
work thorouqhout the life cf the project. Norden linked the 
cycles to obtain a project profile. When the individual 
cycles are added together, they produce the profile of the 
entire project (figure 2.3). 




Figure 2.3. Project Profile 

Peak manloading time (t ) culminates during final stages 

d 

of development and implementation (figure 2.4) . Based upon 
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Figure 2.4. Manloading Profile 



Norden's studies f 5 5 J , cumulative resource allocation up to 
this time accounts for approximately forty percent of the 
life-cycle. Occuring at the low end of the curve is the op- 
eration and maintenance phase which absorbs the remaining 
sixty percent of life-cycle expenditures. The greater por- 
tion of costs associated with this phase are attributed to 
the " maintenance tail*' or expected life cf the software pro- 
duct. Failure repair, however, is just a small part of 
Dost- delivery maintenance activities. Studies [56] show 
that coding errors account for only thirty percent of the 
post-delivery errors. The greater share (seventy percent) is 
occasioned because there is a mistake in design cr specifi- 
cation. Although the code performs exactly as designed, this 
does not reflect the original operational desires. 
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Logically, it would seem that maintenance manpower 
requirements would decrease over time due to growth in reli- 
ability. In other words, as programming and design errors, 
which are commonly called "bugs", are found and corrected, 
the time to the next system failure should increase through- 
out the maintenance phase of the life-cycle. This reliabil- 
ity assumption, however, is disputable. Maintenance action 
taken in response to error cccurance can have three possible 
outcomes : 

1) the actual error is corrected; 

2) the error is corrected, but the fix induces a new 
error ; 

3) the error is not corrected, and the program remains 
non-o perational. 

Reliability growth, then, is a probabilistic event which de- 
pends heavily on the skills of the maintenance programmers. 
If the mair.tainers are competent, reliability should grow. 

Another controversial assumption is growth in maintain- 
ability. When maintainability is viewed as the time re- 
quired to return a software system to an operating status 
following a system failure and maintainability growth is 
viewed as the decrease in time required to correct an error, 
then an obvious conclusion would be growth in maintainabil- 
ity. Several factors, however, may produce an opposing 
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conclusion, i.e. decaying aaintainabilit y. Patchwork fixes, 
in addition to introducing new errors, may produce module 
interface problems and documentation inefficiencies will 
complicate the finding of other errors. Reduced familiarity 
with a software system, stemming from frequent personnel 
turnover, can be an inhibitor. Documentation and software 
(programming) standards and controls may not be enforced on 
new releases. Error identification and correction may be- 
come further entangled when configuration control is lax. 
Again, the competence of the maintainers will influence the 
results. 

C. LIFE-CYCLE INTERRELATIONSHIPS 

The management process for the maintenance of software 
involves decisions in establishing control of changes to the 
software and in providing for the implementation of improved 
functional capability throughout the life-cycle of the soft- 
ware. The planning to acquire and implement resources for 
software maintenance must: 

1) consider the entire life of the software, and 

2) begin early in the life of the software in order to 
reserve funding and identify sufficient resources for 
the future. 
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Different time spans and levels of effort exist for the 
different phases of a software project. The failure to ob- 
tain quantitative relationships of a precision comparable 
to those available for estimating the costs of hardware sys- 
tems has led to the belief that interrelationships exist 
among life-cycle phases. That is, the amount of resources 
used in early phases impacts heavily cn the resource re- 
quirements for later phases. Using an approach similiar to 
basic economic production theory, Thibodeau and Dodson [57] 
developed a mathematical model to describe the complexity of 
the phase interrelations. This relationship is given in the 
form: 

a b 

Q = AK L (2.2) 

where 

Q = the level of output, 

K = the amount of capital input, 

L = the amount of labor, and 

A, a, and b are empirically derived constants. 
Graphically, this is shown in figure 2.5. 

To add a term representing technological change or to 
account for different classes of labor or capital, the num- 
ber of input resources can be expanded to 

a 1 a2 b 

Q = AK K L (2.3) 

1 2 
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Figure 2.5. Economic Production Curve 
In order to indicate trade-offs between life-cycle phases, 

the same general formulation can be used and expressed as 

b c d k 

P = aX X X X (2.4) 

d c t m 

where 

P = software production resulting from the applica- 
tion of the resources, 

X = person-months of inputs, 

a, b, c, d, and k are empirically derived con- 
stants, and 

subscripts d, c, t, ra represent designing, coding, 
testing, and maintenance respectively. 

A further assertion made by Thibodeau and Dodman indi- 
cated that limitations in design resources (e.g. a reduction 
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in planned resources) may be passed through the development 
phases with final impact in the maintenance phase (higher 
error rates) . Based on the mathematical postulate previous- 
ly described, this type of relationship can be shown by the 
graph in figure 2.6. 



PM 

Coding 
cr 

Testing 

Maintenance Effort 

Figure 2.6. application of Production Theory 

In describing the infinite set of relationships, table I 
illustrates some departures from the ideal which may occur, 
and how a reduction or increase of resources in these phases 
will be reflected in the error rate of the delivered soft- 
ware. While it can be argued taat the ideal error rate may 
be zero, a more practical solution would be to avoid de- 
dicating an enormous amount of resources to achieve zero 
errors. As a result, it would be expected that for most 




information systems, planning would allow for some marginal 
error rate. However, this tolerance of errors does not nec- 
essarily apply to tactical defense systems. 

D. S OFT W APE EVOLUTION 

Operational software systems undergo a continuing pro- 
cess of evolution, the phases of which are repair, modifica- 
tion, enchancement, and adaptation. Continuing evolution is 
the visible sign of continuing interaction between the sys- 
tem and its environment. Even if — and this rarely, if 
ever, occurs — its first implementation was perfectly con- 
ceived, perfectly designed, and perfectly implemented, a 
program will require general maintenance. 

Evolution dynamics is a theory describing the change of 
a software system over a period of time. The theory distin- 
guishes between p rogr essi ve work (to introduce new features) 
and a nt igr e ssive work (fault correction, testing activity, 
and investment in methodology to combat the complexity which 
grows with system size) [53]. The basic assumption of pro- 
gramming evolution dynamics is that it is legitimate and 
necessary to view a large program and its maintenance orga- 
nization as interacting systems. Thus one must search "for 
models that represent laws that govern the dynamic behavior 
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TABLE I 



Hypothetical Phase Interrelationship Trade-offs 



Hypothetical cases 



I 1 



Analysis and design > 



Coding and checkout = < < 



Testing 



Maintenance 



Changes 



No No No No Yes Yes No No 



Reported error rate < > 



> > 



> > 



Symbols: 



= equal to ideal 
> greater than ideal 
< less than ideal 
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and program ma- 



of the metasystem of organization, people, 
terial involved in the creation and maintenance process" 
[ 59, 60 ]. 

Feedback is basic to the process since the system and 
system designers are considered as a metasystem. The key to 
good feedback is intensive use over time. The more the 
software is used, the better it gets, as long as deficien- 
cies are fed back into the maintenance group and corrections 
are made. This statement holds true provided that the main- 
tained introduce fewer errors than they resolve. Likewise, 
the longer it is used the less the probability that the sys- 
tem contains major deficiencies. In analyzing a software 
development system, a simple beginning would be as shown in 
figure 2.7. When pressure is exerted to provide bigger re- 
leases (later versions of a system that contain enhancements 
and/or corrections) , the results are more complexity, re- 
duced quality, and growth rate limiting factors. Eventual- 
ly, releases are made solely for restructuring/rewriting. 
At this point, a fission effect is possible where excessive 
growth leads to system breakup. 

Various published papers [61, 62] have discussed the 

characteristics and dynamics of the evolution of large 
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Figure 2.7. Development Release Cycle 



programs, with the most significant contribution cf research 
done by Lehman and Belady [63, 64]. Their efforts were di- 
rected at understanding the dynamics of the software life- 
cycle, thereby creating an enhanced environment of manageri- 
al awareness and an understanding cf system behavior. Long 
term unpredictability of the system development and mainte- 
nance processes have been attributed to the human interface. 
However, it has been found that measures of system activity 
such as number of modules handled, inter-release time, and 
total number of modules in the system, show an unusual 
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regularity. Sines this regularity could not be attributed 
to management decisions, Lehman and Belady have tried to 
analyze it through the use of evolution dynamics. By de- 
scribing the environment of program creation and maintenance 
in terms of regularities, trends, and patterns, they have 
proposed laws governing the evolution dynamics (table II) . 

Features of these evolutionary trends were further sup- 
ported in a mere recent study by Leintz knd Swanson [65]. 
Analysis of data obtained from an extensive survey indicated 
chat the magnitude of a maintenance effort can be explained 
by the combined efforts of four variables: system age, sys- 
tem size, relative amount cf routine debugging, and the re- 
lative experience of the maintainers. The relationships of 
these variables were modeled as shown in figure 2.8. Amount 
of maintenance effort, the dependent variable, is seen to be 
influenced through five other causal paths involving four 
variables. Each causal path is initiated from the indepen- 
dent variable, system age. 

E . PRODUCTIVITY 

Productivity is often considered a measure of the trans- 
formation of meaningful and controllable units of input to 
meaningful and controllable units of output. The question of 
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TABLE II 



Laws of Evolution Dynamics 



CONTINUING CHANGE 

A program that is used and that, as an implementation 
of its specification, reflects some otner reality, 
undergoes continuing change or becomes progressively 
less useful. The change or decay process continues 
until it is judged more cost effective to replace the 
program with a recreated version. 



INCREASING COMPLEXITY 

As an evolving program is continuously changed, its 
complexity, reflecting deteriorat ina sturcture, in- 
creases unless work is done to maintain or reduce it. 



THE FUNDAMENTAL LAS 

(OF PROGRAM EVOLUTION) 

Program evolution is subject to a dynamics which 
makes the programming process, and hence measures of 
global project and system attributes, self-regulating 
with statistically determinable trends/invariances. 



CONSERVATION OF ORGANIZATION STABILITY 
(INVARIANT WCRK RATED) 

The global activity rate in a project supporting an 
evolving pregram is statistically invariant. 



CONSERVATION OF FAMILIARITY 
(PERCEIVED COMPLEXITY) 

The release content (changes,, additions, deletions) 
of the successive releases or an evolving program is 
statistically invariant. 



quality must be understood in all 
if they are to have meaning. It 
productive when producing threwawa 
producing high quality output. 



measures of productivity, 
is far easier to be more 
y products than it is when 
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Figure 2.8. Casual Paths of Maintenance Effort 

If software is sized in terms of a product measure such 
as the number of instructions or modules, then the assumed 
personnel productivity against those measures is a key vari- 
ant in the estimate. Since producing software is a very 
labor intensive activity, consuming greater than eighty five 
percent of the resources allocated for software development 
f 66 ], an essential ingredient for arriving at an accurate 
cost estimate of the software lies in personnel productivi- 
ty. Generation cf software is creative and, therefore, a 
wide variance across personnel productivity can be expected. 
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3udget estimations required fcr software development 
have led to an abundance of research exploring the topic of 
programming productivity [67, 68, 69] Traditional measures 

of software productivity have included: 

1) dollars per defect, 

2) lines of code (LOC) per person-month (PM) , 

3) dollars per LOC, 

4) dollars per PM, and 

5) complexity branch per 1000 LOC. 

Maintenance researchers pose the yet unanswered ques- 
tion: Can the same criteria be applied for productivity 

during the maintenance phase? Within a maintenance scenar- 
io, module constituents of a software application can be 
categorized as new, modified, retained, and converted (fig- 
ure 2.9). New segments consist of entirely new code. Modi- 
fied segments are composed of changed code and the unchanged 
code that may be affected by the changed code. Retained 
code consists of previously developed and tested segments 
that will be integrated into the software products without 
being modified. Converted code is existing code converted 
to another language. Each of the categories of code, wnen 
related to a specific product, may produce a unique proauc- 
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Figure 2.9. Categories of Program code 



Factors which influence productivity have been widely 
researched. Data collected from sixty projects by Walston 
and Felix showed that significant rela tionships existed 
between productivity (SLOC) and the ratio of developed code 
to the sum of original (or reused) code plus the developed 
code [70], The resulting plot shown in figure 2.10 suggests 
-.hat productivity is highest when there is no original or 
reused code, that is, when all the cede is developed from 
the inception of the project. As the percentage of reused 
code grows, the expected productivity decreases. 
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Figure 2.10. Productivity - Reused Code Relationship 

Recent investigations done by Swanson and Leintz, re- 
vealed that while productivity techniques have been exten- 
sively discussed, few systemic studies of benefits in the 
maintenance phase have been conducted [71]. Figure 2.11 
shows some, but not all, of the factors commonly cited as 
indices of productivity. 

Maintenance costs must be viewed collectively with pro- 
ductivity. To do less is to focus on only part of the 
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Figure 2.11. Productivity Determinants 

t could be a misleading focus if management dic- 
icies that result in high productivity during de- 
work but adversely affect the productivity of 
very maintenance. If the productivity is negative- 
ed because of internal problems prior to delivery 



issue. I 
tates pol 
velopmant 
post-deli 
ly affect 
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or reduced quality when in use, then costs will increase and 
affect the potential to complete other projects. 



F. COMPLEXITY METRICS 

Quantitative metrics which assess the complexity of 
software continue to attract a high degree of interest. 
These metrics are assumed to be valuable aids in determining 
the quality of software. A collection of such metrics which 



assess numerous factors that constitute this nebulous "soft- 
ware quality" have been proposed [72, 73]. Such factors in- 
clude reliability, portability, maintainability, and myriad 
other xxx-abilit ies . 

Potential uses for measures which assess these various 
factors are manifold. Importance of metric relationships 



lies in the following areas: 



1) As feedback to programmers, they can be used during de- 
velooment to indicate potential problems with developed 
code‘[74]. A design is evaluated with the metric rela- 
tionships in mind. If it appears that this design falls 
outside of the metric bounds, then another design must 
be contemplated. 



2) In guiding software testing, McCabe's cyclomatic number 
has been proposed as a means or assessing the computa- 
tional complexity of the software testing problem [75], 
Other metrics which index the quality cr complexity of 
software may help identify modules or subroutines wnich 
are likely to be most error-infested. 



3) If one of a combination of metrics can be empirically 
related to the difficulty programmers experience, then 
more accurate estimation can be made of the manpower 
that will be necessary during maintenance. 
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In using these metrics, it is important to distinguish 
between the computational and psychological complexity of 
software, since reasons for assessing them differ. C ompu ta- 
t ional com p lexit v refers to "the quantitative aspects of the 
solutions tc computational problems" [76] such as comparing 
the efficiency of alternate algorithmic solutions. To il- 
lustrate, as the number of distinct control paths through a 
program increases, the computational complexity may in- 
crease. Psychological complexity refers to characterist ics 
of software which make it difficult to understand and work 
with. Psychological complexity can then be thought of as 
assessing human performance on programming tasks. Subse- 
quent sections will discuss currently used metrics that have 
been coupled with the maintenance effort in an attempt to 
predict programmer effort required to complete a specific 
maintenance task. 

1 . Halstead 1 s E 

During the last few years research aimed at the de- 
velopment of a "software science" has supported the conten- 
tion that there may be simple theoretical explanation for 
the structural characteristics of many computer programs and 
that there is a strong quantitative relationship between 
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these characteristics and the effort required to writs pro- 
grams [77, 18, 79], Based on the theory of software sci- 
ence, five entities of an algorithm expressed in a language 
are measureable: 

= number of distinct operators, 

n = number of distinct operands, 

2 

N ^ = total number of operators, 

N = total number of operands, and 
2 

* 

n^ = number of input/output parameters for the 
algorithm . 

From these measurements, some defined properties for pro- 
grams can be calculated: length (N) , vocabulary (n) , volume 

(V) , and program level (L) , [80] 

Using the simple relationships between these metrics 
and the effort (E) required by a programmer, Halstead ar- 
rived at an expression of effort (total number of elementary 
mental discriminations) to generate a given program where 



n N (N + N ) log (n + n ) 
V 12 1 2 2 1 2 




3y applying the Stroud number, which is the number 
of elementry pieces of data that a person can mentally sep- 
arate per second (S) , a dimension of rime is introduced to 
the effort equation: 
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e v 




where T indicates the estimated time fcr programming. Ex- 
cept for the Stroud number, all parameters on the right side 
of the equation are directly measureable for any implementa- 
tion cf an algorithm. Research methods using calculated T 
values have shewn that a strong correlation exists with the 
actual time measurements in the absence of certain "impuri- 
ties" which correspond to common undesirable programming 
practices such as unstructured code, low module cohesive- 
ness, high module coupling, etc. [81]. 

2. M cCabe* s v(G) 

More recently, T. McCabe [82] developed a complexity 
definition based on the decision structure of a program. 
McCabe's metric is the classical graph theory cyclomatic 
number v (G) defined as: 

v(G) - number of edges - number of nodes 

+ 2 (number of connected components). 

Two simpler methods cf calculating v (G) are presented by 

McCabe: the number of predicate nodes plus 1 or the number 

of regions computed from a planar graph cf the control flow. 

Literally, this complexity metric counts control 
path segments which, when combined, will generate every 
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possible path through the program. Since additional control 
paths could make a program more difficult to understand, the 
number of basic paths indexed by this metric may also relate 
to mental difficulty of a programming task. 

G. ERROR PREDICTION 

If managers knew how a program behaved for every con- 
ceivable combination of inputs and could accurately predict 
all future input combinations, then they would knew precise- 
ly how many errors are in that program and could predict at 
which point in time that the program would next fail. As a 
result, it would be fairly simple to program resources for 
software maintenance. The only real decision, then, would be 
whether the annoyance from the error was worth the effort to 
eliminate it. Because this ideal situation is not a realis- 
tic representation of the world, except in the most trivial 
programs, it would be a great aid to managers to have a 
method to predict residual errors with a reasonable degree 
of certainty. This capability would arm them with a good 
guide for programming the amount of maintenance effort need- 
ed for the next time period. 

In the early days of computing, managers obtained rough 
estimates of the number of errors in a nodule by assuming 
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that there was one tug in every sixty lines of code or 
perhaps in every cne hundred lines of code depending on each 
manager*s optimism and experience £833. It seems to be a 
reasonable assumption that there is a better way to predict 
residual errors. The importance of error detection analysis 
has been recognized in the past few years and many studies 
have addressed this problem. [84, 85, 86, 87, 88, 89, 90, 
91] An important objective of most of this work has been 
to develop analytical techniques to examine the error phe- 
nomenon in order to compute or predict items of interest 
such as the number of errors detected at time t, the pre- 
sumed number of remaining errors at time t, and the software 
reliability function. (It should be noted that none of 
these studies deals specifically with the detection or the 
prediction of errors during the maintenance phase of the 
software life-cycle.) 

One would expect software reliability to improve with 
age because latent bugs are detected and are presumably cor- 
rected. However, there are exceptions tc this general state- 
ment. Bugs can be induced into programs while corrections 
are being made. This situation, called the "ripple effect", 
generally happens in very large systems like 0/S360 instead 
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of small systems like a compiler [92]. When a change is 
made in module ’A' it affects the way module 'B' works. The 
maintainer has neither the desire to change another module 
nor, probably, any idea that his change would affect another 
module. With vast, complex systems it is impossible for any 
person to know all of the ramifications of a change. Since 
most operational software is subject to enhancements and 
changes in requirements because of the dynamic environment 
in which it is run, it can be expected that bugs will be in- 
duced with the new code and that other modules will be af- 
fected through interfaces with the new modules. In the long 
run however, it appears that most software projects follow 
the predicted process and have fewer errors as time elapses 
[93]. Table III [94] provides data to support this phenome- 
non. Observe the great variability of the data and the in- 
creased reliability as time passes. 

Although the code appears to become more reliable as 
time passes, there are still problems with error prediction 
models. Many of these models assume a constant error rate 
[95, 96, 97, 98, 99]. This does not strike one as being a 
reasonable assumption on three accounts. First, the failure 
rate will fluctuate because the frequency of execution of 
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TABLE III 



Successive Execution Times Between Failures 
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the areas cf code varies. Some areas may never be executed 
[100]. As an example, if one assumes that there are one 
hundred bugs in a program, that the failure rate is fifty 
failures a week, and that one is using a constant error rate 
prediction, then after fifty bugs have been eliminated the 
failure rate should be to be twenty-five failures per week. 
If the bugs are eliminated in the order that they are de- 
tected, the first fifty tc be eliminated would be in the 
most frequently exercised areas of code and the observed 
failure rate would be less than twenty-five per week. If, 
on the other hand, the most severe errors were corrected 
first, there may be a situation where there are several an- 
noying but non-critical bugs in a highly exercised portion 
of code and the observed failure rate is forty failures per 
week despite having eliminated fifty bugs. 

Second, according to Ottenstein [101], the error rate 
for modules, at the validation and integration stage, varies 
inversly with the size of a module. This theory has been 
corroberated by Motley and Brooks [102]. Motley and Brooks 
feel that this inverse proportion is an indication that 
the larger modules were not as fully debugged during the 
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validation and integration stages and would go into the op- 
erations and .maintenance phases with a greater proportional 
amount of errors. Ottenstein explained the phenomenon in 
just the opposite manner. She feels that there is a learn- 
ing and retention benefit that operates with large modules 
and thus the larger modules will go into operations and 
maintenance with a smaller proportional amount of errors. 

A third reason for a variable rate of errors at the 
validation and integration phase is also proposed by Otten- 
stein [103]. Earlier developed modules are more fully de- 
bugged in the initial testing because at that period in the 
project there is a lot of time and money to do the job cor- 
rectly. However, modules that are developed near the end of 
a contract appear to be hastily and incompletely debugged 
before being submitted for validation because both rime and 
money are running out. The authors propose a corollary to 
this hypothesis. The more over-budget and behind-schedule 
that a project is delivered, the higher should be the pre- 
diction of errors detected in the maintenance phase. 

Sven if a manager could accurately predict the number of 
errors that will be detected in a given time period, there 
would still be a problem in scheduling the proper amount, of 
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resources. 



Different types of errors will require different 



amounts of effort for correction because they are of differ- 
ent complexities. 

H. CHAPTER SUMMARY 

Numerous software topics are under study in an attempt 
to uncover explanations for the phenomenology of the soft- 
ware life-cycle. Of more specific concern are the events 
which lead to the increased expenditures during the opera- 
tion and maintenance phase of the software project. Indica- 
tions from research evidence are that not one single factor 
can be named as the dominant contributor to the life-cycle 
maintenance costs. Instead, a multiplicity of factors are 
cited as having an impact on the total system. 

Recognizing the futility of identifying a single con- 
tributor, reseachers have resorted to finding the control 
elements that best define the changes that occur in system 
characteristics. With a continued research effort, better 
understanding and increased familiarity of these system con- 
trol elements may lead tc positive results in linking sys- 
tem characteristics with maintenance requirements. 
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III. COS T estimation of soft war e mai nten a nce 

Coupling the rising costs of computer software with the 
relative decline in computer hardware costs would indicate 
that computer software acquisition cost and maintenance and 
operation cost (collectively referred tc as software life- 
cycle costs) constitute the greatest share of the data pro- 
cessing budget. Consequently, predicting future software 
costs for both existing systems (maintenance and operation 
costs) and new development is of increasing concern to 
management . 

The phenomenology of the software development and 
maintenance process is not definitively known. Research 
suggests the existence of a fairly clear time-varying pat- 
tern such as a Rayleigh curve or seme ether similiar form. 
The analysis is complicated by the presence of '•noise*' or 
stochastic components. Additionally, the observable compo- 
nents (manpower, cost, time) are strongly subjected to man- 
agement perturbation. This would indicate that although a 
system has a characterist ic life-cycle behavior, if that be- 
havior is not known to managers a priori, then they will 
respond reactively (non-optimally with time lags) to system 
demands. A reasonable basis now exists for expecting that 
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an adequate phenomenological description may arise from the 
following sources: 

1) statistical mechanics; 

2) information theory coupled with statistical communica- 
tion theory; 

3) diffusion and transport theory. [104] 

Tracking of costs throughout the life-cycle is important 
because, as pointed out in chapter Two, sixty percent of the 
life-cycle effort is consumed during the operations and 
maintenance phase. If this phase is treated as a level-of- 
effort task, then far more resources than necessary for 
maintenance are used. Given a fixed manpower or budget 
constraint (very common in government) , less than optimal 
control of the work during this phase increases the possi- 
bility of maintenance work saturation (i.e. devoting all re- 
sources to maintenance) . This situation leaves no capability 
to accomplish additional work. 

Within the scope of this discussion, three types of 
models for addressing maintenance cost estimation will be 
considered: 

1) software cost estimation from a macroestimating view 
using the Ncrden-Rayleigh curve parameters; 

2) software cost estimation from a microestimating view 
using a work breakdown struct ure (W ES) methodology; 

3) software evolution dynamics using system complexity as 
a cost monitor. 
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The format of presentation will include a general descrip- 
tion of the model with subsequent application of the model 
to the forecasting of costs within a maintenance scenario. 

A. SOFTWARE COST ESTIMATING MODELS 

1 • Putnam ' s Soft ware Cost Es t i mati ng M odel 
a. Description 

This model attempts to provide quantitative an- 
swers to the questions often asked by managers about soft- 
ware projects. These questions are generally concerned with 
project time duration, total cost, and the accuracy of the 
figures presented. Putnam's [105] methods provide estimates 
in the following areas: 

1) Total life cycle effort in manyears; 

2) Cost for the project; 

3) Peak manpower needed; 

4) Manpower needed at any specific time or phase in the 
project ; 

5) Risk and variance analysis of derived estimates; and 

6) Linear programming (L?) techniques to impose real world 
management constraints. 

Putnam's contribution tc software cost estimat- 
ing was tc apply the Rayleigh curve to software life-cycle 
manloading. Using the techniques based upon the life-cycle 
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theory developed by Norden, Putnam did a number of empiri- 
cal studies and found that the software life-cycle exhibits 
a rise in manpower up to a peak and then a trailing off. 

Basically, the Putnam model obtains estimates of 
the measure of work in man-years and of the total develop- 
ment time of the project. Development time in the Putnam mo- 
del is defined as the elapsed time on the project up to the 
point when the system reaches full operational capability, 
but not including the system definition and functional 
design/specification phases. The estimates of the total life 
cycle in man-years and the development time are then used to 
derive an equation giving the ordinates for a man-power ex- 
penditure curve for a specific project. A yearly dollar 
costing can then be computed for the project by muitipying 
the ordinates cf the man- power curve at each year by the av- 
erage cost/man-year to arrive at a dollar cost/year and, 
subsequently, at a total dollar cost for the project. Put- 
nam uses the Raleigh equation, which has been empirically 
determined to fit the project manpower loading profile for 
large projects and to best represent Norden’s model. The 
most popular form of the curve is the derivative form and is 
expressed by: 
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= the curve shape parameter, 

= the elapsed time in years, and 
= the exponential function. 

With the assumption that the shape of the curve 

related to both the difficulty of a particular 

and tc the skill level of the project team, a 

expressing these relationships in terms of Ray- 

parameters was derived. The relationship of the 

to development time (t ) is: 

d 

2 

= 1/2t (3.2) 

d 

substituted into the derivative form of the Ray- 

, results in the following equation: 

2 2 
„ “(t /2t_ ) 

2 a 

= K/t te (3.3) 
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To use the above equation. 



estimates must be 



found for the total life cycle in man-years (K) , and the 

development time (t ) . Virtually every parametric software 

d 

cost model is based on an estimate cf computer program size, 
measured in either source statements or object code instruc- 
tions. Putnam uses source statements because that is what 
programmers produce. Likewise, it simplifies the mathemati- 
cal computations because compiler efficiencies are not con- 
sidered. The relationship that is used by Putnam to equate 
source statements to development time and project effort is 
given by the following equation: 



Ss 



Ck*K 



( 1 / 3 ) 



t 

d 



where 



( 3 . 4 ) 



Ss = delivered source lines of code, and 
Ck = state-of-technoiogv constant. 

Within the model, estimating program size is 
viewed as an iterative process that should be recomputed 
several times during the system definition and functional 
design/specification phases in the software life cycle. The 
first estimate is done at project conception and can be lit- 
tle more than a best guess used to establish basic economic 
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feasibility based on past software projects and expert opin- 
ion. As sore knowledge is gained about the project, indivi- 
dual segments of the system are estimated seperately and 
then totaled to give a more accurate estimate of the expect- 
ed size. Also, standard deviations and confidence intervals 
are derived from statistical methods that use best and worst 
case estimates. 

To determine the technology constant, data from 

past software projects must be inserted into the software 

equation (3.4) tc derive the unknown variable Ck. It should 

be noted that Ck is initially very difficult to determine 

but should remain consistent for similar projects within a 

specific organization. After the parameters Ss and Ck are 

determined, various values of t and/or K may be substituted 

d 

into the software equation to produce a parametric graph 
showing size versus effort and time (figure 3.1). 

A constraint line determined by management and 
representing a difficulty gradient for certain types of pro- 
jects is then superimposed on the graph. Values mat fall 
below this line are determined to be infeasible for software 
development . 

After values and ranges are found for t and k. 



62 




MY 



MY 



MY 

MY 



UU 



Figure 3.1. Size vs. Effort and Time Relationship 

dollar costs for the project may be computed by multiplying 
plying an average labor rate per man-year by an expected 
value of man-years tc derive an estimated total cost for a 
project. A variance estimate for dollar costs may be ob- 
tained in a similar manner from the variance of man-years, 
'/ihile this model recognizes that real world managerial 
constraints exist, they are not explicitly addressed. In- 
stead it is recommended that linear programming techniques 
should be used to account for everyday concerns such as 
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contract, deadlines, cost ceilings, and hiring practices and 
capabilities. 

b. Application to Maintenance Costing 

Putnam's model takes a macro approach to answer- 
ing the questions most often asked by managers concerning 
the areas of time, effort, and cost. According to relation- 
ships determined empirically, an overall estimate of man 
power is obtained and subsequently allocated among the 
different phases. To determine the risk involved in the es- 
timation, statistical methods are used which give the manag- 
er a 'feel' for the accuracy of the data presented to him. 

As work proceeds during the life-cycle, uncer- 
tainty about the management parameters decrease. In order 
to follow and track the time-varying behavior of a software 
system, empirical data must be collected and plotted to show 
the currant labor force for any given time (figure 3.2). 
Osing this data stream, time series analysis can be done. 
3y turning the characteristic Rayleigh behavior into a 
straight line, the actual manpower data may be fitted to get 
a revised estimate of future resource consumption. 

The linear form of the Rayleigh-Nor den curve is 
illustrated in figure 3.3. This form may be obtained by di- 
viding equation 3.3 by t and taking the natural logorithm of 



64 



MY/Y B 



o 



0 



o 



o 



o 



o o o 



1 1 I i I I I I I I I 



Time or FY 



Figure 3.2. Typical Plotting Structure 



the result. This yields 



2 2 



2 




(3.5) 



which fits the familiar linear form v = mx + b. 

Actual data is set up in a table form with addi- 
tional calculated data points that are needed for the cor- 
responding plot. Hypothetical data from Table IV is plot- 
ted in figure 3.3 with the best straight line fitted to the 
data points (determined by eye or calculation). 

From this plot, Hayleigh parameters can be cal- 
culated. The slope can be used to compute development time 

2 

(t ), while the intercept (K/t ) , given the value of t 
d d d 

just obtained, yields the value of total effort, K. Calcu- 
lations for determining these values are listed with the 
figure. 
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TABLE IV 



Hypotheical Project Data 



t 


y' 


y'/t 


t 


In (y '/t) 


1 


68 


68.0 


1 


4.22 


2 


70 


35.0 ' 


4 


3.55 


3 


1 06 


35.33 


9 


3.56 


4 


1 18 


29.50 


16 


3.38 



Projected management estimates can be calculated 
by extending the line to subsequent year points (figure 
3.4). Continuing with the same example data, future man- 
loading predictions are made by applying the sequence of 
equations contained in figure 3.4. 

Similiarly, resource estimation for additional 
outyears may be computed. As mentioned earlier, this model 
is an iterative procedure. Each year actual project data is 
added to the table. The data points are replotted and the 
best fit straight line is again determined. New values for 
the slope and intercept are found and projections are then 
made based on these new values. 
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Ln(y'/t) 




Slop e Calcu la tic ns 

y _ -T -i 

Slope ”x ~ 22 2 ~ " 

2t 

d 



take reciprocals. 



2 

= 22 
d 



2 

t =11 

a 



= 3.32 years 



Interc ep t calcul ations 

I = 4. 0 = Ln (K/t ) = b 

d 



2 

Ln (K/t ) 
d 

e =4.0 



2 

K/t = 54.6 

d 

2 

K = 54.6 t 

d 



K = 54.6 * 11 

K = 601 manyears 



Figure 3.3. Fitting the Best Straight Line 
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Ln (y'/t) 




Projection _fqr M year 5 
t = 3 years 



Ln(y'/t) = 2.85 



2.85 

y'/5 = e 



2 • 85 

y* = e (5) = 17.29 (5) 



y' = 86 people (manyear/y ear) 



Figure 3.4. Line Extension and Prediction 



2 . Ar my Macrce st imat i nq Mod el 
a. Description 

Realizing that there was a need for a simple, 
effective, reasonably accurate procedure for estimating and 
controlling resources. Army Headquarters analysts produced a 
comprehensive macroestimating procedure for allocating the 
appropriate manpower commitment to an application system at 
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any point in the system life cycle [106]. The procedure 
enables users to forecast the size of a new application 
software project and suggests the manlcading necessary to 
accomplish the project workload. 

Some functional estimators for the project man- 
ager include: 

1) optimum man-loading over life-cycle; 

2) total manpower over life-cycle; 

3) cost per year; 

4) risk profiles;and 

5) scope of applicability. 

Initial analysis of all United States Army Com- 
puter Systems Command (USACSC) systems yielded a database 
from which statistics have been derived that permit estab- 
lishment of control limits on resource allocation at any 
point in the life-cycle of a system. Additionally, numeri- 
cal correlation points between effort/unit time and normal- 
ized time were established for system development mile- 
stones. Using these points, the project manager can plot 
the project life-cycle profile of a software development ef- 
fort in terms of the time that various milestones should be 
reached and the level of resources (manpower) that should be 
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applied to the system development at those points (figure 
3.5). 

Excursions outside statistically determined control limits 
shown in figure 3.5 should trigger the action officer to 
take corrective action. 

Using the mathematical relationship developed by 

N orden. 



2 

-at 

y 1 = 2Kate 



(3.1) 



step-by-step procedures were developed for estimating system 

variables for the following cases. 

( 1 ) Case I : S ystem a lre ady unde r development 

( reso urces budgeted) . Using budget data, the maximum level 

of manpower (y* ) and the number of years to reach maximum 

max 

effort (t ) is determined. Rather than compute the values 

y' 

max 

for outyear manpower loading. Table V is used to compute the 
values of y* for the appropriate t . By multiplying any 

y ' 

max 

antry opposite its time period by K, the appropriate number 
of manyears are obtained. The units of K and t will deter- 
mine the demensicns. 
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MY/YR 



Y ' max 




START t tMaint 

Y' max 

0 1 2.38 

NORMALIZED TIME (t/t ) 

Y • max 



DESIGN CERTIFICATION 
first 
expected 
last 



0.235 

0.4 33 



0.618 



SYSTEMS INTEGRATION TEST 

first 0.550 

expected 

last 



0.660 

0.76 8 



PROTOTYPE EVALUATION TEST 

fir st 0.613 

expected 0.800 

last 



EXTENSION 

first 



exp ecte 
last 



d 



0.613 

0.930 



0.990 



1.25 0 



MAINTENANCE 

first 

expected 

last 



2 . 096 



2.38 



2.853 



NOTE 1: 



NOTE 2: 



First and last are at five percent probability lev 
el..i.e. there is a ninety percent probability tha 
t/tymax will lie between rirst and last for a par 
ticular milestone event. If net, ask questions. 

Tabular entries are in normalized time units. 



Figure 3.5. 



Milestones Applied to Project Profile 
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TABLE V 



Ordinates for Manpower Function 



t It 1 

j y ' aiax j 


1 


2 


3 


4 5 6 7 


0| a 1 


.50 


.1250 


. 0556 


.0310 .0200 .0139 .0120 J 


1 | 


.60653 


. 22062 


. 10510 


1 

.06057 .03920 .02739 .020201 


2 1 


.27067 


.30326 


. 17794 


.11031 .07384 .05255 .309181 


3 | 


.03332 


. 24349 


.20217 


.14153 .10023 .07354 .05585| 


4 1 


. 00134 


. 13533 


. 18271 


.15163 .11618 .08897 .069331 


5 | 


.00001 


. 05492 


. 13852 


.14307 .12130 .09814 .07906J 


6 1 




.01666 


.09022 


.12174 .11682 .10108 .084801 


7 1 




.00382 


. 05 1 1 2 


.09461 .10508 .09845 .08664| 


8 1 




. 00067 


.02539 


.06766 .08897 .09135 .08497| 


9 1 




. 00009 


.01110 


.04475 .07124 .08116 .08036| 


10| 




. 00000 


.00429 


.02746 .05413 .06926 .07356| 


1 1 1 




. 000 00 


. 00147 


.01567 .03912 .05691 .065301 


12| 






.00044 


.00833 .02694 .04511 .05634| 


13| 






.00012 


.00413 .01770 .03453 .04729| 


i a i 






.00002 


.00191 .01111 .02556 .03866| 


1 5 | 






.00000 


.00082 .00666 .08130 . 030 8 1 | 


16 | 






.00000 


.00033 .00382 .01269 .02395| 


17 | 








.00012 .00210 . 00853 . 01 8 17 | 


1 8 | 








.00004 .00110 .00555 .01346| 


19 | 








.C0001 .00055 .00350 .00974| 


20 | 








.00000 .00026 .00214 .00639| 
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(2) Case II: New system (no r esourc e data) . 

Total man-years of effort and peak time for manpower loading 
is estimated using Bayes' theorem. [107] Based cn empirical 
data from internal systems, a probability versus K density 
function was derived without regard to type of system. 
Further analysis determined frequency of system type and 
probability of occurence of each type. Using estimates 
based on past USACSC experiences (the average K value for 
all systems under development and average K for the func- 
tional type of system) , initial estimates for a new new de- 
velopment are calculated from regression graphs. Then, by 
applying Bayes' theorem tc average these individual esti- 
mates in the weighted probability sense yields a better es- 
timate of K with a smaller standard deviation (i.e. better 
confidence in the estimate) . To improve estimates and re- 
duce uncertainty, Bayes' theorem is sucessively applied, 
b. Application to Maintenance Costing 

USACSC empirically determined that all of their 
systems reached a steady level of effort (maintenance level) 
on the average of 2.38 times the amount of time that was 
used to reach maximum effort. This relationship can be ex- 
pressed as: 
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t = 2. 38t (3.6) 

maint y* 

max 

In applying this equation, a system, with maximum level of 
effort reached at year three, would reach a steady state at 
7.14 years . 

The level of effort associated with the steady 

state maintenance phase was empirically determined by USACSC 

to be twenty-three percent of y 1 with a ninty percent 

max 

confidence interval from eight percent to thirty-eight per- 
cent of y' . At that point in the project life-cycle, 
max 

when 2.38t (twenty-three percent of y* ) is reach- 

y' 

max max 

ed, using numbers generated from the manpower equation 

(3.1) should be discontinued and a constant level of effort 

of twenty-three percent of y' should be used until the 

max 

system is replaced. Figure 3.6 shows a generalized 
control-limit envelope of a ninety percent confidence inter- 
val for the resource level. 
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NORMALIZED RESOURCES/UNIT TIME 
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0.B 

0.6 
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0 



(ALLOCATIONS OF M-Y/YR SHOULD REMAIN 
WITHIN THESE UPPER AND LOWER BOUNDS 
UNLESS THERE IS A KNOWN CAUSE.) 

DIMENSIONS ARE IN NORMALIZED UNITS TO 
DETERMINE TIME FOR ANY SYSTEM, MULTI- 
PLY BY t v < . TO GET MAN-YEARS, MULTI- 

” max 

PLY 8Y Y* 



— + 1 STD ERROR 



a v .,/Y « 0.25 (USACSC DATA) 
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1.6 (7 y t /Y = i 0.40 



90-PERCENT C.I.+ 

NOT MORE THAN 5 PERCENT OF 
USACSC BUDGET PROJECTIONS 
SHOULD BE ABOVE THIS LINE. 



EXPECTED RESOURCE LEVEL 




-1 STD ERROR 



3.0 18 



NORMALIZED TIME lt/t tf - ) 

’ max 



Figure 3.6. System Resource-Control Limits 



B. SOFTWARE EVOLUTION MODEL 
1 . Leh man-B slady Model 
a. Description 

There have been several attempts made to assess 
resource allocation to achieve the repair or modification 
required for a single release, which is a new version of a 
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system. A variety cf data has been collected relating to 
module handle rate and release interval. Based on experi- 
ence in dealing with different environments, it has been 
suggested that development and maintenance trends exist giv- 
ing rise to complexity measures. These measures, in turn, 
can be determined by the average number of old module han- 
dlings per new module and per fault fix, respectively. 

As systems evolve over a series of releases, the 
ratio of changed modules to the total number of modules have 
been found to mcnotcnically increase and approach unity. 
This ratio is an observed and directly measurable quantity 
which describes the system's property of resistance to 
change. Of importance is the indication that the number of 
modules involved in a system modification is likely to be 
proportional to the effort spent. [108, 109] 

Belady and Lehman proposed a model in which ac- 
tivity is of three kinds: progressive ( F) , antigressive (A) , 
and additional work related to system complexity (C) . It 
was hypothesized that a balanced budget (B) implies that at 
any time 

B = P + A + C. (3.7) 
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Although simple, the model captures two important aspects of 



evolution dynamics; the sharing of the resources between 
progressive and antigressive effort (where both A and C are 
considered antigressive) and the absorption of total budget 
and further growth limitation by the inevitable rise in the 
cost of complexity. 



from neglect of A activity. Removal of resulting cumulative 
neglect can be accomplished only by a temporary increase in 
A. If the total budget, B is limited, the result is a tem- 
porary decrease in progressive activity, P. It is assumed 
that B, P, A, and C can be measured in cost per unit time. 
The cost function is expressed in the following fashion; 



KP = inherent A activity required for each unit of 
P activity to prevent complexity growth; 
m = management factor, the fraction of KP actually 
dedicated by management to A activity (0<m<1) ; 
an d 

7" = a time constant. 



Increase of C activity is hypothesised to stem 



Cost (t) 




( 3 . 8 ) 



where 



77 



b. Application to Maintenance Costing 

Preliminary analysis and simulation have been 
carried out using a non-linear differential equation model 
of evolution dynamics. It has been found that the model is 
capable of reproducing some important phenomena observed in 
data that can be related to observed characteristics of the 
system. 

In figure 3.7, the simulation shows that the 
code production rate (the progressive element) increases to 
a maximum of about 225 modules per year. At the end of the 
first year, the complexity has increased to the point where 
such a production rate cannot be sustained with the budget 
available, since an increasing resource demand is being made 
by A and C activity. A balanced budget requires a reduction 
in P activity, which later leads to a reduction in A activi- 
ty. By year six, the system has reached its limiting size 
with the resources available. 

Although results seem promising, a great deal of 
work must be done before practical results in the form of an 
accurate predictive model can be achieved. From figure 3.7, 
it would seem apparent that application of control theory 
to modules developed earlier may result in a substantial 
payoff in financial terms. 
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Time (years) 

Figure 3.7. Growth Rate Simulation 

2 . Parr Model 

a. Description 

Putnam and Norden have prepared a Rayleign curve 
model for the rate at which resources are consumed by soft- 
ware engineering projects. One of the models main assump- 
tions is that the initially rising work rate is due to a 
linear learning curve governing the "skill" available for 
solving problems at time t. This assumption is questionable 
because a linear learning curve is not theoretically sup- 
ported, and the skill available on a project depends on the 
resources which have been applied to it [110]. Thus, this 
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assumption confuses intrinsic constraints on the rate at 



which software can be produced with management's economical- 
ly governed choices on how to respond to these constraints. 

Parr asserts that the rate of progress on a 
software project is primarily determined by dependencies 
among the problems which must be solved. Some problems can 
be solved in parallel whereas others can only be handled se- 
quentially. Let W (t) be the number of problems which have 
been solved at time t and V (t) be the number of visible un- 
solved problems at time t which can be solved (i.e., all 
earlier required problems solved) . When a problem is solved, 
W (t) increases by 1; V (t) , however, may increase or decrease 
depending on whether or net the problem solved makes new 
problems invisible/solvable. It is reasonable to assume 
that problems solved early in the project will lead to more 
unsolved problems, and that those solved later will have a 
higher probability of not making new unsolved problems visi- 
ble. A crude approximation to this is to assume that the 
probability of a solved problem not generating more unsolved 
problems is iinearly proportional to the number cf problems 
solved. [Ill] 
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How does the above relate to the rate at which 



development programs can be made? Clearly, management can 
reduce the rate of progress by supplying inadequate re- 
sources. There is also an upper bound to the amount of ef- 
fort which can be usefully applied. Hapid progress using 
large amounts of input resources is possible only when there 
is scope for solving problems in parallel. In practice, a 
different programmer (or possibly a team of programmers) can 
be assigned to each separate visible unsolved problem. This 
suggests that the rate at which useful work can be applied 
is proportional to V (t) , and that with this "optional” input 
effort, steps in the development will be achieved at a rate 
proportional to V (T) . 

Whereas the Rayleigh model proposes that the 

rate of progress will be proportional to the skill level and 

number of problems remaining, the above has argued that it 
is proportional to the visible unsolved problem set. A 
mathematical expression yields: 

2 

7(t) = (1/4) seen ((t + c )/2) (3.9) 

a hyperbolic function symetric in t with an integration con- 

stant c ; while the Rayleigh function is: 

2 

- t /2 

= y * tr ♦ <0 



V (t) 
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(3. 10) 



2 

The sech model closely resembles the Bayleigh model in the 

latter half of the curve, but the front tail is positive 

rather than zero like the Rayleigh (figure 3,8). Thus, in 
2 

the sech model, projects dc not have well-defined starting 
points. This accounts for work done prior to the official 
project starting date. 



workrate 




One cf the principles of software programming is 
that decisions initially made should be high-level struc- 
tured ones which identify components for subsequent refine- 
ment. Increasing the complexity of the initial decisions in 
this manner is equivalent tc varying the distribution of the 
probability of a solved problem generating unsolved ones. 
3y modifying the assumption that this probability is linear, 
a modified workrate function can be derived: 
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V(t) 



__A_e (22_ait) 

1/2 

(1 ♦ A exp (-2 o/ 1 ) } 



(3.11) 



Thus, it may be seen that whereas the Rayleigh 
model of software development proposes that the rate of pro- 
gress will be proportional to the skill level and number of 
problems remaining, this section has argued that it is pro- 
portional to the size of the number of the visible unsolved 
node set. 

Results obtained from the proposed model are 
similiar to the Rayleigh model, except that account is taken 
of work contributing to a project wnich precedes its offi- 
cial starting date. The proposed model has been shown to be 
sufficiently determined for it to be possible to account for 
the effect of different programming methodologies on the na- 
tural work associated with the project. 

b. Application to Maintenance Costing 

Parr suggests that exhaustion of the problem 
space is the main cause for decrease in maintenance effort 
at the end of the project profile curve. In addition, the 
structure of the software product achieved during the devel- 
opment could affect the project work profile. While appli- 
cations to maintenance costing have been addressed in 
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concept only, implications are that integration techniques 
for determining the area under the curve at a specific time 
pe- riod will produce results similar to those obtained by 
using Putnam's model. 

C. CHAPTEB SUMMARY 

With the intent to gain management control of predicting 
maintenance costs, various software cost estimating methods 
and philosophies derived from observing trends and patterns 
in the development cycle are being extended to encompass to- 
tal system costs. Supportive evidence for the accuracy of 
the models discussed herein is contained, for the most part, 
in software life-cycle simulations. It is anticipated, how- 
ever, that the acute interest and increased awareness shown 
in the resource investments attributed to software mainte- 
nance will be viewed more critically. Although lacking in 
substantial procf for predictive validity, these models 
serve as stepping stones in producing a composite model for 
tracking maintenance costs. 
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IV. MANAGING SO FTW ARE MAINTEN ANC E COSTS 



Previous chapters have addressed topics that are being 
critically examined for their impact on the software mainte- 
nance phase. They also discussed the application of current 
development software cost estimation techniques for obtain- 
ing maintenance ccszs. The focus of this chapter will be 
the presentation of a method for arriving at a well- 
structured view of the management of the maintenance phase 
of the software life-cycle. While a mathmatical model which 
accurately explains the phenomena of the maintenance phase 
still remains elusive, a planning and control model has been 
developed to aid project managers. The structure of the mo- 
del embodies two distinct concepts: 

1) a planning concept - development of the management 
stratecy to cement the perceptions of the maintenance 
issue ; 

2) a control concept - procedural analysis for estimating 
the maintenance' manloading requirements. 

Subsequent sections will address application of each as- 
pect of the model in depth. 
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A. PLANNING CONCEPT 

1 • Proje ct Management 

Primary responsibility for development of a manage- 
ment strategy belongs to the project manager designated to 
manage the system plan. As project manager, one must ini- 
tially determine and define the maintenance requirement of 
the mission profile for the system that is to be designed 
(i.e. built-in maintainability). 

Factors which must be considered early in the formu- 



lation of a maintenance plan include: 



1) Probability of change in requirements. While it may be 
impossible tc define adequately the complete require- 
ments for a large program, viewing the type of system 
application (business, scientific, command and control) 
and utilization rate will serve as indicators for the 
amount of flexibility to be considered in the system 
design. 

2) Software performance requirements. Again, application 
type is the dictating force for analyzing this factor. 

3) Hardware life-cycle. In planning for software mainte- 
nance, the interaction of the Hardware and software 
life-cycle must be taken into account. 



2 . Obj ectiv es of the Maintenance Co ncept 

Derivation of maintainability requirements from the 
description of the operational requirements provides tne 
support planning criteria on which to base the maintenance 



concepts appropriate to the maintainability requirement. 
The maintenance concept, which basically defines criteria 
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governing the sccpe and methods applicable at each echelon 
of maintenance, attempts to satisfy the quantitative main- 
tainability requirement derived for the system and the plan- 
ned support environment within which the system will oper- 
ate. Early development cf the appropriate maintenance 
concept will provide a definitive and uniform basis for ac- 
complishing the system design and support planning tasks. 

3. Est ablis hing the Maintenance Policies. 



System effectiveness is jointly dependent on several 
parameters, of which performance characteristics, system re- 
liability, and operational availability appear to be the 
most critical. In effect, these parameters set baseline re- 
quirements or constraints which may have impact upon the de- 
sign process depending upon the maintenance policy that has 
been established. While a boundless number of policy varia- 
tions may exist, the following four categories identify the 
range of policy choices. The basic distinction among these 
four categories lies in the amount of resources invested 
over time and the cumulative benefit received over time. 
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a. Category I - No Management Control 

A steady maintenance effort is applied with no 
attempt for configuration control which is ensuring that a 
master copy of all operational software is maintained. Com- 
plexity of the program will eventually reach the point where 
locating errors and/or making changes becomes exceptionally 
difficult. Gradually, the program becomes less useful until 
it must be discarded and a new program developed. This 

policy may prove to be cost effective for situations where 

it is known that the nature of the application will limit 

the useful life cf the program. 

b. Category II - Permanent Support Level with 

Periodic Redevelopment 

As in Category I, a steady level of maintenance 
support is provided by a permanent workforce. Redevelopment 
or a new release can be planned for at regular intervals or 
in response to a specific quantity of change requests. 

c. Category III - Error Repair with Major Changes 
Manpower support is set at the level needed to 

correct program bugs. External programming support would be 
required for making major changes. 



88 



d. Category IV - Error Repair Only with Periodic 
Redesign 

As in Category III, manpower is set at the level 
needed to correct an unacceptable design error or program 
bug. Change requests are used in establishing specifica- 
tions for subsequent design of a new program. 

4 • Managem ent Structure 

Since the level of repair policy must be comparable 
with the maintainability requirement, the maintenance con- 
cept must te defined for each management level of mainte- 
nance established. Beginning with the lowest level of us- 
ers, maintenance concepts are implemented with subsequent 
policies for higher management levels developed to support 
the user level concept. To illustrate, maintenance may be 
divided into three echelons as discussed below and shown in 
f i g ur e 4.1. 

1) User level. Maintenance may be restricted to failure 
reports and system restarts. 

2) Organizational level. Technicians perform corrective 
maintenance. Tasks performed would include location of 
fault, module repair, and testing. 



3) Contractor level. Maintenance performed at this level 
may be used to supplement (augmented support) or to 
reDlace (sustained support) the organizational level 
support. 
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Activity 


User 

Level 


Organization 

Level 


Contract 

Level 


| Where 
performed 


Remote or 
local site 


Facility 

having 

project 

cognizance 


Agency and/ 
or contract 
facilities 
as required 


Who performs 


Maintenance 

personnel 


Maintenance 
division or 
support team 


Contract 

personnel 


Maintenance 

action 


Restore 
system to 
operational 
status 


Locate mod- 
ule errors; 
repair and 
return to 
user 


Locate mod- 
ule errors; 
repair and 
return to 
user 


Maintenance 

tasks 


Inspection 
and restarts 
minor 

repairs and 

adjustments 

submit 

change 

requests 


Module 
reoair ; 
major coding 
modifica- 
tions, 
testing 


Complex 
repairs, 
modifica- 
tions; major 
codina; 
rebuilds 



Figure 4. 1. Maintenance Levels 
5 • System Life-cycle O bjectiv es 

Utimately, the maintenance objective is to achieve 
the required level of maintainability in delivered systems 
with an optimum balance between resource support require- 



ments and poxential life-cycle costs. In order to meet this 
objective, it is necessary to begin the system life-cycle 
with the appropriate concepxual approach. As the software 



product passes through several distinct phases in ixs evolu- 
tion, maintenance prospects can be enhanced if adequaxe ax- 



tenticn is taken in each phase. 



90 



Figure 4.2 depicts the life-cycle as a simple 
phase-to-p base flow diagram, joined by critical transition 
points where it can be ascertained that the required main- 
tainability objective has been achieved before transition to 
the next phase. These transition points are denoted in the 
figure as major achievement milestones. Each phase compris- 
es several areas cf management endeavor in which the consid- 
eration of the system maintainability is essential to the 
attainment of milestone objectives. The software product is 
re-examined at each milestone to determine the future course 
based on progress up to that point. As each milestone ob- 
jective is met, maintainability becomes progressively more 
tangible as a built-in feature of design. Maintainability 
milestone requirements are summarized in the figure. 

Milestone criteria can best be satisfied by syste- 
matic application of approved procedures in the performance 
of evaluation, management, and control tasks which are 
geared directly to specfic objectives of individual mile- 
stones in the life-cycle. A basic approach to maintainabil- 
ity achievement as an evolutionary phase- to-phase 'growth 1 
process is shown in figure 4.3. 
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Concept Formulation Phase Milestone Criteria. Maintain- 
ability requirements derived; maintenance concept estab- 
lished; maintainability documented in system specifica- 
tions; maintainability milestones and task requirements 
document ed. 

( 1) Proceed to design phase. 

Design Phase Milestone Criteria. Maintainability design 
approach and maintenance concept optimized by tradeoff and 
conformance to specified requirements and economic consid- 
erations; maintainability requirements and milestone 
criteria updated. 

(2) Proceed to code phase. 

Code Phase Milestone Criteria. Conformance to specified 
maintainability requirements and maintenance concepts ver- 
ified by evaluation; maintenance control procedures de- 
fined in support documentation. 

(3) Proceed to test phase. 

Test Phase Milestone Criteria. Maintainability degrada- 
tion factors verified by test and evalution; maintenance 
concepts. repair policies, and maintenance procedures 
are verfied. 

(4) Software product is approved for delivery. 

Service Ose Phase Milestone Criteria. Maintainability 
characteristics, maintenance prodecures, and support costs 
determined by periodic assessment of management data; 
problem areas identified for correction. 

(5) Initiate change request, product enhancement or new 
development; repeat life-cycle. 



Figure 4.2. Maintenance Milestones in the System Life-cycle 



3. CONTROL CONCEPT 

1 . Ob j ectiv e of Mainte nance Contro l 

The objective of this thesis was to develop a 
methodology for arriving at a good prediction of pure 
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LIFE-CYCLE PHASE 



TASK AREA 


CF | D | C | T 1 S 


TASK REQUIREMENTS 


Determine 
Maintain- 
ability 
Requir e- 
men ts 


* 


* 








° Establish H policies 
° Derive M requirements 
° Optimize M to relia- 
bility, availibility , 
and supportability 
° Evolve conceptual 
design criteria 


Specify 
maintain- 
ability 
require- 
ments and 
milestone 
criteria 


£ 


* 


* 


* 




° Define M requirements 
° Define M milestone 
criteria and task 
requirements in 
pregram documentation 
° Specifically outline 
foregoing requirements 
in contractual 
documents 


Achieve 
specified 
maintain- 
abilit y 
in design 




* 


* 


* 




0 Identify and define M 
problems and critical 
areas 

° Integrate M enhance- 
ment into design 
° Verify design conform- 
ance to specific 
requirements 
° Review impact of pro- 
posed changes on a 
design characteristics 


Show ade- 
quacy of 
maintain- 
ability in 
develo p- 
ment 






* 


* 




° Prepare detailed plans 
for maintenance test 

° Demonstrate adequacy 
of maintenance manuals 


Achieve 

optimum 

mainte- 

nance 

support 


* 


♦ 

1 


* 


* 


* 


° Develop maintainence 
plan, repair policies, 
and procedures 
° Develop maintenance 
training program 
° Prepare contractor 
support plan 


Evaluate 

maintain- 
abilit y 

at service 

level 










* 


° Verify conformance to 
M requirements under 
service conditions 
° Verify adequacy of 
maintenance support 
manuals 

° Evaluate skill 
requirements and 
adequacy of training 
program 



CF = Concept Formulation E = Design 
C = Code I = Test 

S = Service Use 



. Maintenance Tasks in the System Life-cycle 



Figure 4.3 
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maintenance costs. Determining the requirements for pure 
maintenance is considered valuable in that 

1) estimates can be calculated of the manloading necessary 
to form a maintenance support team which is composed of 
either in-house or contract augmentation; 

2) projections can be made for outyear maintenance support 
and availability of manpower resources for developmen- 
tal work. 

With future research, the application of this model 
may be extended to any software project; however, access and 
availability of data precluded analysis of small and medium 
sized projects. Only data from major projects was analyzed 
for developing a computational algorithm. 

In executing the computational algorithm, both macro 
(system) and micro (functional area component) techniques 
are used concurrently tc increase the validity of the esti- 
mates. An implicit assumption worth noting is that each 
method should provide reasonably close estimates for the 
same project. The macro technique, of course, is based on 
total system characterist ics and will provide the gross man- 
ning requirements directly. Alternately, from the micro 
technique, summation of the decomposed functional areas will 
yield the gross manning for the total system. 
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2. Model Deriviaticn 



The data under study was taken from a large-scale 
project reported by USACSC £112] and unpublished data from 
the IBM Space Shuttle Program [113]. 
a. Macro Technique 

Using the Bayleigh curve parameters derived by 
ilorden and Putnam [114, 115], a method was constructed for 

obtaining total system maintenance requirements applicable 
to the established management strategy. In his early work, 
Norden made note of the fact that the Sayleigh curve of a 
project profile has a point of inflection at which the de- 
crease in utilized manpower slows down in the descending 
portion of the curve. 



t 



ip 




(4.1) 



where 

t = the inflection point of the project curve 

ip 

a = the shape parameter or spread of the curve. 



The point of inflection may have more signifi- 
cance than originally recognized. If it can be shown that 
the level of effort for the maintenance phase reaches a max- 
imum at this point, the manlcading estimate calculated from 
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this point can he used as the upper bcund for maintenance 
support. In essence, the current model suggests a new 
mechanism for determining the level of maintenance support 
required. Gained from the model is the benefit of relating 
the work profile more directly to the intrinsic structure of 
the project profile. 

To simplify calculations, the project profile is 

normalized with respect to t and y* as shown in figure 

d max 

4.4. Total life-cycle (K) , has a normalized value of 1. 
Based on this assumption and using Rayleigh curve relation- 
ships, it can be shewn empirically that the peak of mainte- 
nance effort occurs at the inflection point. 




96 



9 



the shape 



From the normalized curve values 
parameter is found with the following relationship: 



1 

a = = 0.5 

2 

2t 

d 



(4.2) 



Substituting this value of a in the following equation, the 

inflection point (t ) of the project profile is obtained. 

ip 



3-P 



3 

2a 



, 1/2 



1.73 years. 



(4.3) 



Manloading requirements at time t (y‘ ) 

ip 1.73 

can be shown mathematically to be equal to the maximum man- 
load (y* ) which occurs at the peak (t ) of the maintenance 

t m 

m 

phase profile. Stated in the format of a mathmatical equa- 
tion, this equality has the form 



(project inflection 
point manning) 



or 



y* 



(maximum maintenance 
phase manning) 

y • 



(4.4) 



IP 



Substituting normalized values into the Rayleigh (manpower) 
equation 



y ' = 2(1) (.05) (1.73) e 

(1.73) 

y* = 0.38 manyears. 

(1.73) 



(-. 05) ( 1 .73) 



(4.5) 

(4.6) 



97 



In order to calculate maximum manning for the 

maintenance phase, parameters for the maintenance curve must 

be defined. Actual time elapsed between the beginning of the 

maintenance phase (t ) and the maximum level (t ) is comput- 

o m 

ed using empirical data recorded by USACSC. Results from 

the USACSC research indicate that the maintenance phase, 

which accounts for twenty percent of the total life-cycle 

manpower ( K ) , begins at approximately 1.3 years normalized 

time. With this estimation, actual time elapsed (t ) can be 

e 

found by 

t = t - t = 0.43 years. (4.7) 

e m o 



The spread of the maintenance curve (a ) is 

m 

determined by sufctituting the elapsed time value into the 
already familiar equation 



1 

a = 2.71 (4.8) 

m 2 

2 (t ) 
e 



The value obtained for the shape parameter suggests a curve 
having a wide spread, an expected characteristic of the 
maintenance phase profile curve. Computation of the maximum 



manloading for the maintenance phase from the basic manpower 



equation gives 
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2 



y' 



(t ) 
01 



2 (. 2K) (2.71) (. 43) e 



(-2.71) (.43) 



(4.9) 



y ' = 0.38 = y' (4. 10) 

(t ) (t. ) 

m ip 

With y* defined to be the upper boundary for 
m 

the maintenance effort, another boundary can be identified 

as the lower limit for maintenance effort. By determining 

the value of the inflection point of the maintenance curve 

(t ) , a minimum support level can be found from 
im 



3 \ 



1/2 



za 



= .74 years. 



(4.11) 



Converting this time to normalized time (t ) 

n 



t = t + t (4. 12) 

n o im 

t = 1. 3 + . 74 = 2.04 years (4.13) 

n 

and substituting this value in the manpower equation yields 

y* = .25 manyears. (4.14) 

(2.04) 

The manpower loading calculated for the inflec- 
tion point of the maintenance phase (t ) closely apprcxi- 

im 

mates the value identified by USAC3C as the steady state 

level of effort. Establishing maintenance at rhe minimum 

level can be interpreted as a Category IV policy. 
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b. Micro Technique 

Decomposition/ more commonly referred to as the 
work breakdown structure (WBS) method, has been a predomi- 
nate methodology for estimating manning resources. A system 
is considered to contain subsystems which are further divid- 
ed into smaller hierarchial structures until the smallest 
programing element is reached. Once the functional areas 
are defined, characteristics (complexity, productivity, er- 
ror rate, etc.) of each must be reviewed to determine the 
level of effort needed for maintenance. Appendix A contains 
an example of a micro-estimating methodology along with the 
sample data used. 

3 . Sample Ap pl ication 
a. Sample Data 

Data used for this sample application of the 
control concept was provided by IBM Federal Systems Space 
Shuttle Program £116]. The raw manning data is provided in 
Appendix A. The remainder of this section is a step-by-step 
example of the ccmputicnal algorithm which implements the 
control concept of the proposed model. 
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MY 




Project Curve Pa r am eters 

t = 2.5 
d 

K = 1343 

a = . 08 

Y' =325 
max 



M ainten ance S upport Lev el 
(1) Macro technique 



t 

ip 


4.33 




y t 

(4.33) 


207 


manyears 


t 

im 


5.1 


years 


y' , e „ = 


137 


manyears 



(5.1) 



UOTU T ~ 

MSB = maintenance support 
boun dary 

Boundary level established 
from analysis of macro and 
micro estimations. 



(2) Micro technique 

y = component manning 
c 

Vy = 195 manyears 
u c 



(refer to Appendix A) 



Figure 4.5. Plotted Sample Data 
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b. Computational Algorithm 



St ep J. Fit the actual budget data to a Ray- 
leigh curve. Figure 4.5 shows plotted data for the Space 
Shuttle program. 

Step 2. Determine maintenance support boundary 
lines by calculating the inflection points cf both the pro- 
ject profile and maintenance phase curve. 

Step 3. Determine support level requirements 
using micro-estimating techniques. 

Ste£ 4. Compare values obtained from macro and 
micro methods. Analyze the differences from an economic 
standpoint based cn management policy. 

S tep 5. Predict outyear budget requirements for 
maintenance/new development contingent on management policy, 
c. Management Applications 

Although the results shown here relate to only 
one set of data, they are encouraging in the support they 
give the model. The model presented in this thesis could 
provide a direct means to evaluate the impact of current and 
future management practices on the life-cycle cost of tne 
software system. The idea of the development of a mainte- 
nance strategy coupled with the use cf the computational 
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algorithm provides the project manager with some powerful 
management tools. While additional research is warranted, 
it is purported that application of the model will prove 
enlighting in the following respects. 

(1) De termin in g Mai nten ance Support Le vel. 
Preliminary estimates obtained from inflection point predic- 
tors may be used as a starting point for planning workforce 
requirements to be drawn from internal assets. Likewise, if 
external or contracted support must be procured, evaluations 
of submitted bid proposals will be necessary. Although yet 
unproven statistically for accuracy, the inflection point 

predictors appear to define maximum (t ) and minimum (t ) 

ip im 

boundaries for maintenance levels. 

In accordance with the type of maintenance 
strategy chosen, a maintenance level boundary can be select- 
ed. For example, if a Category IV policy is selected, man- 
power needs would approach the minimum boundary. On the 
other hand, a Category I policy would require resources ap- 
proximated by the maximum level. With these boundaries to 
serve as guidelines, contract proposals can be viewed more 
critically . 
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(2) Fo reca stin g R eso u rc e Di str i buti on. Whether 
an internal or external workforce is used, planning ana 
budgeting estimates of manloading are usually projected for 
discrete timeframes. During the maintenance phase of a via- 
ble project, the workforce in terms of total number remains 
stable; however, the work distribution or functional roles 
of personnel may change (i.e. programmers may shift from 
maintenance work to development work) . Within governmental 
agencies, this stability may be attributed to fixed contract 
levels or established manning levels, neither of which can 
be easily changed. Therefore, the management problem be- 
comes one consisting not only of how many personnel are 
needed, but also hew can assets best be utilized. 

In light of the fact that the users have 
changing requirements, the issue of workforce allocations 
for new research and development must be considered. Based 
on the Rayleigh curve characteristics for a specific project 
and using a fixed support level environment, approximate 
values for workload distribution can be calculated. 

Ey method of integration, the proportion of 
the total support level force that will be dedicated to pure 
maintenance and/cr new development in future timeframes can 
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be calcalated. 



Figure 4.6 illustrates this point using the 



sample data. 



MY 



y' 




2 -at 

MSB - 2Kata dt 



= 20 7t 



16 



2 

-at 

- 1 343e 



6 

5 



= 101 MY (resources available for new development) 

Note 1: 

MSB = maintenance support boundary. In this example, the 
boundary is established at the project profile inflec- 
tion point. Alternately, the boundary would be estab- 
lished to indicate the manning level of the mainte- 
nance workforce. 



Figure 4.6. Forecasting Future Requirements 



Maintenance 
oversight method is twofold, 
work (enhancements, additions 



information gained 
The separation of 
new design) from 



with this 
development 
maintenance 
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work (debugging, design error correction) is accomplished, 
thereby allowing for better interpretation of the project 
investment. The comparison of the relative proportion of 
maintenance manning versus development manning for reviewing 
project viability can also be made. This concept will be 
discussed more fully in the next section. 

(3) Monitoring Configurati on Co ntr ol, k pauci- 
ty of available data prevents the comparison of actual and 
predicted manpower that is required during the maintenance 
phase. The assumption that the maintenance tail is flat or 
reaches a steady state seemingly arose from this lack of in- 
formation. It is the authors' contention that new releases 
of a software product may, in fact, cause increases in the 
maintenance tail ever time. 

Lehman and Seiady's [117, 118] research, 
discussed in chapter 3, gives strong indications that subse- 
quent releases for a software product increase complexity 
and the amount cf antigressive (maintenance) work than is 
required for the total system. Two inherent characteristics 
of the software product directly affected by a new release 
are the system configuration and the size of the system 
problem space. From a project profile view, the time period 
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when these new releases occur is during the maintenance 
phase. 'With the assertion that the work allocated to the 
completion of a new release must he considered as a phase 
within the project life-cycle, the increase in maintenance 
costs can be explained. 

As the diagram in figure 4.7 indicates, the 
changes induced by the release phase will cause the level of 
maintenance to increase. Unless carefully monitored, each 
new release may cause an increase in the maintenance re- 
quirements until the original maximum maintenance support 
level is reached or exceeded. When this occurs, management 
is forced to make a cost-benefit assessment of the software 
system. 

Using the concepts introduced earlier (in- 
flection point predictors and resource distribution fore- 
casting) , maintenance saturation of the software system can 
be detected. The support line obtained from the inflection 

point oredicter (t ) serves as a guideline for total system 

ip 

saturation. Management policy sets forth limits for corres- 
ponding maintenance and/cr development expenditures whrch 
establishs a budget saturation level. These saturation 
levels may be equal or different. In an attempt to preclude 
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NORMALIZED PROJECT PROFILE 




Note 1 : 



MSB = maintenance support boundary 



SSL = system saturation level, equivalent to curve inflec- 
tion point where any maintenance above this level 
would be considered antigressive 

BSL = budget saturation level, established by management 
where possible values may be: 

BSL = SSL 
BSL < SSL 
BSL > SSL 



Figure 4.7. New Release Effect on Maintenance Level 
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excessive maintenance costs, the saturation level viewed as 
dominant is used to trigger management's attention -coward a 
system rebuild. For the subsequent rebuilt system, a new 
Rayleigh curve is plotted and a new cycle of planning and 
contol begins. 



C. CHAPTER SUMMARY 

Presented in this chapter is a bilevel model for manag- 
ing software maintenance costs. The model, composed of both 
a planning concept and a control concept, suggests that the 
creation of a management strategy will have far-reaching ef- 
fects in the system total life-cycle costs. Used concur- 
rently, the two model concepts allow for smoother transla- 
tion of maintenance objectives between the strategic 
olanning level ar.d the operational control level. 
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V. 



SUMMARY, CONCLUSIONS, AND REC OMMENDATIONS 



Presented in this chapter is a summary of the thesis, 
general conclusions, and recommendations for further study. 

A. SUMMARY 

Various methodologies and system factors relating to 
software cost accounting have been reviewed in an attempt to 
develop a cost model for the prediction of pure maintenance 
costs. The distinction between development costs and 
maintenance costs is considered necessary in order to pre- 
sent a realistic picture of the annual expenditures within a 
given budget constraint. Without a refined separation of 
these two cost entities, budget control is a more difficult 
task. 

Beginning with a broad background of what maintenance is 
and is not. Chapter One uncovers the paradox that exists in 
obtaining a consensus for a common working definition of 
maintenance. Different schools of thought within the mili- 
nary and civilian research fields have produced inconsisent 
results when citing the proportion of the the life-cycle 
costs attributable to total system costs. This inconsis- 



tency may be due. 



in part, to the range of cost types (new 



development, pure maintenance, other administrative support 



activities, etc.) that exist during the maintenance phase. 
While some researchers may view each cost type individually, 
others consider the maintenance costs to be an aggregate of 
all expenditures during the maintenance phase. 

In Chapter Two, an overview of the extrinsic and intrin- 
sic charactistics of a software system which create the 
maintenance setting is provided. It is apparent from the 
detailed discussion of the more salient concepts that the 
maintenance issue is not only complicated, but also still 
somewhat elusive. While these concepts have been useful in 
explaining system charact eristics and predicting future be- 
havior, they fail to produce a means for direct translation 
to a monetary value. 

Although no cost estimation technique adaptable for man- 
agement use has teen developed solely for predicting mainte- 
nance costs, application of software cost estimating schemes 
originally intended to evaluate the development phase have 
been extended tc include the maintenance phase. Chapter 
Three is devoted to a review of various models that have 
been suggested as appropriate for addressing the maintenance 
cost uncertainties. The models two avenues for approaching 
the issue: 
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1) a total system concept using the Ncrden-Sayleigh curve, 
an d 

2) a dynamic system philosophy using software evolution 
analysis . 

Current unavailability of a basic method for adequately 
determining miantenance expenditures and the increasing con- 
cern of DOD for the exorbitant funding required to sustain 
software system operations inspired the authors to develop a 
flexible management model. Chapter Four elucidates a plan- 
ning and control model which can provide project managers 
with additional information to assist in budget planning and 
decision making. This model proffers four maintenance stra- 
tegies which may be used in conjuction with calculated maxi- 
mum and minimum maintenance level support boundaries specif- 
ic to the project profile. 

3. CONCLUSION 

While an abundance of research in software economics and 
software engineering exists, very little has been done that 
relates to the maintenance phase of the software life-cycle. 
As a result, there is an obvious lack of raw data available 
to analyze the proposed model for validity and sensitivity. 

With additional research, it is believed that the model 
presented in this thesis will provide a direct means to 
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evaluate the impact of current and future management prac- 
tices on the life-cycle costs of software systems. The com- 
bined use of the simple macroestimating and microestimating 
techniques allows the manager to look at the maintenance 
problem from different perspectives while increasing the 
confidence in the projected maintenance costs. Additional- 
ly, the computation of minimum and maximum levels of effort 
for a specific project leads to further diminution of the 
problem when management has established a particular mainte- 
nance strategy. 



C. RECOMMEND ATIC NS 



It is recommended 
dertaken to further 
maintenance costs and 



that additional work within DOD be un- 
the research objectives of software 
that zhis work include the following 



act ions : 



1) adoption of a standard definition that will distinguish 
between maintenance costs and costs incurred in the 
maintenance life-cycle phase; 



2) institution of longitudinal research by software sup- 
port facilities to collect maintenance data to be used 
rn the development of management tools with improved 
caDability ; 



3) investigation of the usage of additional prediction 
zools to obtain a more complete view of the domain of 
software behavior during the maintenance phase; and 



4) analysis of empirical data to prove or disprove the 
following statement: The more over-budget and behind 

schedule that a project is delivered, the higher should 
be the prediction of errors detected m the maintenance 
phase . 
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APPENDIX A 



Contained in the following text is a partial sum- 
mary of a microestimating technique (Matrix Estimation 
Process) obtained from IBM Federal Systems Division, 
Houston, Texas. 



MATRIX ME THOD 

Definition: The Matrix Method is a systematic procedure 

which can be used to delineate elements of a 
software project and map them against associat- 
ed cost elements to arrive at a project esti- 
mat e . 

Things that can be accomplished: 

0 Lay out project elements 
0 Stepwise refine the elements 
° Estimate the elements 

° Subtotal the estimates by grouping 

the elements 

0 Total up the group estimates 

° Refine total estimate 



Use of the M atr ix Met h od 

1. Determine functional elements of pro jeer. 

2. Quantify Maintenance needs based on : 

Level = Function Size / ((Productivity) (Complexity) 
(Factor) 

3. Consider critical skills, operations support., and man- 
agement and support. 

4. Summarize for project. 

5. Plot with Rayleigh curve. 
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.Sarri x Estimation P ro c ess 

1. Lay out a table of functional areas of code, require- 
ments areas, test areas, or functions to be performed. 
Using the following formulas, calculate the level re- 
quired to maintain each functional area or function: 



Applications Level 
FCOS Level 


= (FW Size) / ( ( 1 54) (2) (12) (2)) 
= (FW Size) / ( (100) (2) (12) (2)) 


SDL Level 


= (K Line Size)/ ( (15) (2) ) 


Computer Resource 


= (FEID Hrs Wk) / (28) 


GN&C Verfi. Level 


= (Number Test Cases)/((30) (2)) 


SSW Verif. Level 


= (Number Test Cases)/((5) (2) 



SM/PL Verif. Level = (Number Test Cases) /((20) (2) 
Perf. Verif. Level = (Number Test Cases)/((5) (2) 



All Others: 




Level 


= (Development or Support Level) / (2) 


TSO Level 


= Requested support level per site 



2. Look at critical skills to see if each functional area 
is adequately covered. 

3. Estimate error rate and rate of change to see if level 



1 16 



should be altered 



MATRIX ESTIMATE SUMMARY* 









Maint . 


CPN & 






Area 


Size 




Level 


Support 


M&S 


Total 


AASD 


272918 


FW 


42.0 


12. 0 


10.0 


64.0 


CON/QA 






5.0 


— 


1.0 


6.0 


SEC. SUPP 






1 1.0 


— 


— 


1 1 . 0 


AS VO 


1247 


TC 


83.5 


5.0 


15.5 


104.0 








140.5 


17.0 


26.5 


195.0 



Matrix Summary represents decomposition of the Space Shut- 
tle Program intc major functional areas. 



AASD Matrix Esti m at e S um mary * 





Code 


Maint . 


OPN S 






Area 


Size 


Level 


Support 


MSS 


Total 


SM 


54880 


6.7 


3.0 


1 . 3 


11.0 


VCO 


57145 


5.2 


— 


. 8 


6.0 


G NSC 


129918 


16.7 


4.0 


2.8 


23.5 


S . A . 




10. 4 


5.0 


2.6 


18. 0 


P. A. 


30975 


3.0 


— 


. 5 


3.5 


AASD 

MSS 


— 


— 


— 


2.0 


2.0 


Totals 


272918 


42.0 


12.0 


10.0 


64. 0 


Note : 


This table 


illustrates an 


additio 


nal decompositio 




of a major 


functional area 


into subcomponents 


• 
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Plotted Sample Data 




t = 2.5 

a 

k = 1343 



a = . 08 



y* = 325 
max 
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